SpeA-FPGA FPGA design for SPE Phy layer 10 Mbit

Input Pins:

The clr signal comes from a central logic in the FPGA, reset logic. Of course in VHDL also the system clock is part of the input signals.

The rxDin should be immediately connected in the top level VHDL signal from the non filtered and non clocked input pin, which is a difference input.

Inputs from other module:

The only one signal used from other module is the ctDataCy. If this bit is detected in the data receive state, then the next data are CRC code.

Outputs to other module:

The following signals are interesting and provided for other modules in Java via interface. Note that the access in the hardware (VHDL) is done immediately to the adequate FF outputs. The names of the interface routines are exactly the same as the signal names. The interface is related to (the only one) sub module or VHDL RECORD in this module. The interface access offers the possibility for different supplying the signals in a test environment. If a module needs this RxSpe module to work, it is also satisfied with a proper interface implementation in the test bench. This is a proven approach for testing, also used here.

This is done in main/vhdl/modules/common/speA/RxSpe_SpeA.vhd by the

Firstly all processes use a RECORD Type to store the values of this process in states respectively Flipflops (FF) in the real hardware. This record type is here Qrx_REC, the Flipflop-Instance (Output values of the FF) is qrx.

That is the first important spike filter.

This is a simulation result (Simulink) with a hard disturb signal.

The associated model is shown below:

Furthermore in this VHDL code snippet (not in the SImulink), a second qRx.rxD2 is used to store the same signal as in Rx.rxD1 but one 10 ns clock later. With both FF the edge of the input is detected.

This is done in main/vhdl/modules/common/speA/RxSpe_SpeA.vhd by the

This is the Qrx process continued after clr-handling Note that this document contains not all details, refer to the original source. Only the contexts are explained. The source contains maybe sufficient comments.

The FF rxD2 follows rxD1, which is the glitch-filtered data input from the SPE line.

The rxDchg is a local variable in Java and a PROCESS-local variable in VHDL. It is set to 1 if rxD2 and rxD1 are different, means the input signal is changed on rxD1 and in the moment not changed on rxD2.

If an edge is detected, then the ctBitTime is checked:

The ctBitTime is the relevant counter to detect the bits. If this counter is at value 13 = 0b1101 then the time between edges is >= 13. This is the first edge of the start of a new telegram with carrier and sync detection. First it starts without the carrier signal and counts the sync bits from 0. The ctBitTime starts of course from 0 again.

The value 13 is tuned to the clock frequency of 100 MHz = 10 ns and the nominal bit width of 100 ns. It means 9..10 clock edges is the nominal bit width, but 11 and 12 is admissible also. The signal on the SPE wires can be delayed depending on the signal levels up to the switching point on the input.

If an edge occurs in a time ⇐7 clock cycles = 70 ns, then it is not a full bit width. Such edges are necessary as intermediate signal switch to offer the same bit value in Manchester coding. The bit value is the direction of the edge after the full bit time. It means if twice time the same edge should occur then the signal should switch to the other level between. This is the basic of the Manchester coding.

If the carrier signal is false, then this is a faulty edge. It means the carrier detection starts again from ctSyncBits = 0. The edge is not recognized as intermediate edge. Instead, the state before is detected as noise and this edge is interpreted as first edge of a beginning synchronization.

If the carrier signal is given, then this is either a real necessary intermediate edge to offer the same bit value outside the synchronization (data transmission, or the SFD), or it is a disturbance during the synchronization. Such an short disturbance can occur without effect on synchronization itself, as shown in the test results below. For the signal forwarding to the transmitter module the cleaned signal level is used.

The else branch remains for the correct bit time between edges, whereby the shown range is accepted. Then the ctBitTime starts with 0 to measure the next bit width.

The rxDs is the data bit value. It is sampled after an edge after the full bit width. Because rxD1 presents the current level of input, the positive edge is an 1 bit. This is an early time to detect a bit, immediately after a valid bit edge.

The rxD is the bit value regarding necessary negation.

The line with meastime is not related to the FPGA design itself (not translated to VHDL), it is to measure times between signal changes to assert and calculate timing contraints, done at Java level.

If yet sync bytes are expected (!z.dataState), the ctSyncBits counter is incremented till max 0x10 or 16. That are the minimal number of sync bits after them a Start Frame Delimiter (SFD) is expected. This ctSyncBits is set to 0 if in this phase a shorter time between input signal edges is detected:

The carrier signal itself is true if the ctSyncBits is >=2. Here only the bits 4..1 are checked, not the bit0, hence the value 0b00001 results also in carrier = false.

If the dataState is not reached, but the number of ctSyncBits has reached 16, and two times the same data bit is received, then this is the Start Frame Delimiter SFD, signal sfd.

The data level of the SFD can be 0 or 1. Nominal a start frame delimiter is the bit pattern 01011. But if the cable are changed on the plug, it is possible to receive 10100. Then all bits should be negated. This is detected here too.

The next state after sfd is the data state. It is simple to forward the signal level from the sfd FlipFlop to the dataState FF.

The else branch is the dataState as also checked with the assertion. It was set from and hence after active sfd, see block above.

The dataState is so long active as either the number of data words are expired, dedicated with the speRxData_out.ctDataCy from the other module, or if no more edges comes, see next block, with loss of carrier also.

The last block of this PROCESS for bit detection is active if no edge comes. This is of course between the bit time. The ctBitTime is incremented with each system clock. But if the ctBitTime reaches the value of 13 = 0b1101, then the time between edges is too long. It means it is the end of telegram, no signal is given. Then carrier and dataState are switched off.

This lines shows how ce is built. It is simple the moment where the ctBitTime is == 6. This is 60 ns after bit detection after the edge of the input signal. It is before the minimal time for a bit width = 8 is reached. The logic checks only bits 2..0 becasue the maximal value of the counter is 13, hence lesser than the other possible combination 0b1110 of 0bx110. It is an optimization in the hardware given in the source code immediately due to the knowledge of this situation.

The following image shows the functionality:

On start of the input pattern rx1din a noise is given as it is typical for wires with approximately 0 level. Then all noises forces edges. Firstly short 1-spikes comes, then longer 1 signals, and then a long 1 with 0-spikes. All of that is not detected as sync-pattern, because the time between the edges is either too less (on fast signal changes) or too long (no signal change only fast spikes).

The continuation of this simulation run shows a second too long data bit. Later it starts with the following sequence:

This is also a flickering input, but accepted

The disturbances on the bits may be present in the real world, especially as oscillation on the line after the necessary edges. The stronger observation before carrier is detected forces no faulty carrier detection on accidently inputs. The more relaxed observation while carrier state prevents unnecessary aborting of the communication on disturbed signals. Last not least the CRC data check safes the data consistent.

In continuation of the detectInputBit_Prc the time of the bit is observed:

In continuation an edge is checked. It it occurs

The start frame delimiter detection is essential for the frame_out signal also for time synchronization. This is done in the continuation of detectInputBit_Prc:

This is the detectInputBit_Prc continued, after detecting a new bit value after edge.

I/O for SPI:

The spi_MoSi_Pin and spi_Clk_Pin are STD_LOGIC because it should be possible to set it in Tristate 'Z' for test approaches. The spi_MiSo_Pin is always an input, hence BIT is sufficient.

The meaning of this pins should be familiar, see known SPI documentation.

Inputs from other modules:

Outputs to other modules:

This is for the SpeRx_prc: PROCESS (clk100, CE0):

This is for the spi_Prc: PROCESS (clk100, CE0), see Process spi_Prc

This processes the read data from SPI: SPISOMI. Note that the FPGA is the SPI-Master, it offers the SPICLK. Hence this process determines the SPICLK output too. It is a concurrent process because it shold work twice in the 100 ns basic cycle: The SPICLK is produced on qSpi.spiOn and comes with the shown CE signals.

The Spi_Prc runs all with the CE0 clock enable signals. It means all Flipflop of the Spi_Variables have 100 ns possible delay to switch as timing constrain in the FPGA:

This start block shows also the reset condition: Either the clr input is given or all states are zero, condition on hardware reset.

This process reads the data via SPI and shifts it into the qSpi.shDataSpi register:

It shifts the data bit to left to MSBit, first read bit lands in the MSbit after 16 shift operations. This is correct if the SPI interface on the controller is programmed to shift out first the MSB most significant bit for 16 bit access. This is supported by probably all controllers. The 16 bit access should be used to reduce effort on the controller (byte access needs double number of accesses). Shift out first MSB and not LSB was the originally intension from SPI. SPI is not standardized, it is only a "quasi standard". Hence this modus is used here as only one. More modifications seems to be unnecessary. See also chapter Endian approaches: Ethernet Big endian LSB first, SPI: word access, MSB first

To transmit this data it should be shifted in the requested order for the Ethernet bit order rules:

The sequence for the master starts with the frame_inp of the FPGA, here in the simulation tbM_frame, red line. This signal is compared with the qSpi.cmdQ, line below, to detect the leading edge. The trailing edge has no meaning. The leading edge of the frame_inp is Hi→Lo.

After this the SPI reads from the controller 2 * 16 bit, one for cmd, the next for the first data. It is seen on spi_Clk_Pin. The result is the set to

Both values remain in the register, also for the next cycle, because the same values are read in any cycle. That is typical for the application software.

To compare with the sequence on slave:

In the left telegram the slave has no frame_inp, the signal tbS_frame remains on hi. This is given in practice if the slave controller is not programmed yet. But for the second telegram in this image tbS_frame comes. Meanwhile (possible sometime later) the slave controller is synchronized in its interrupt to the SPE data stream, has initialized the SPI interface in the controller and produces the frame_inp signal typical via a PWM output (pulse width modulation). The time synchronization between the SPE data stream and the PWM module and the interrupt to program the SPI interface is done with the signal spi_rxDataState_Inp which is the same as dataState_Out from the RxSpeA module driving the pin frame_out to the controller. Independent of telegram content and SPI communication, the frame_out to the controller can be used for synchronization with a PLL control software (Phase Look Loop). This is a necessary condition for the Ring topology in a fast cycle, because the cycle of SPE communication and the interrupt cycle in the controller to initialize the SPI communication and read and write data should be synchronized. There is no "telegram stack" in comparison to an ordinary Ethernet adapter which does not support such an fast data exchange.

For the slave in the second (right) telegram, now the cmd and data1 are read via SPI. The cmd changes from 0000 (initial) to for example here 2003. It determines furthermore acting as slave. The data1 changes from BAD0 to for example here 4203. That is the sender address.

In the master FPGA the signal txReq_Inp comes in that moment, if the cmd bit 13 is set. This is a signal used in the TxSpeA module. For the next telegram (right side) this signal comes immediately with the frame_inp, this is the red tbM_frame. This is the normal sequence for the master: With frame_inp the transmission sequence starts. But: Because also with frame_inp firstly the FPGA should read the cmd and data1 via SPI, the signal spi_ReqTxData_Inp is delayed in the TxSpeA module, see TxSpe transmit data input to SPE. The TxSpeA module waits a definite time for reading the both data words for cmd and data1 via SPI.

In the moment where spi_ReqTxData_Inp comes the TxSpeA starts with transmission of the SFD start frame delimiter and the first data1 word. This is loaded before, it is a constant data word with usual the same content for all telegrams, it is the sender identification and the length of the datagram.

Now, after spi_ReqTxData_Inp the SPI start working with furthermore accesses to the controller for the following data words. But this access is fine tuned between the timing to transmit via SPE. the timing of receive in the RxSpeA module (should write via SPI) and the SPI timing. For that the short state substatePrep is set (number not visible, between 01 and 08 in the green line qSpi.state).

For that a code snippet from SpiA_SpeA.vhd:

This time fine tuning depends on shift and bit approaches, see next chapter.

The signal spi_reqTxData_Inp (light green line) comes from the module TxSpe transmit data input to SPE

Both conditions indicate the need for new data. Hence the SPI communication starts seen with the spi_Clk_Pin after the correct time. For the first telegram of the slave it hits an uninitialized SPI interface on the controller. It means the controller may not react for the spi_Clk_Pin and the spi_SoMi pin delivers a 0 signal. But this is not used in that state. In the second telegram of the slave all is prepared, as well as on the master.

On the master the signal spi_rxDataState_Inp comes a while after starting trasmission via SPE, here seen on the SPI clock or on the qTx.state. This is the echo in the Ring after all station passing. It is important to consider this relations too: The storing of received data is executed via SPI too, with the same clock. For the slaves that relations are proper: Storing received data and reading the next data to send is anyway hard synchronized, because the received data determines the SPE acitivity and the send data follows this.

But on the master the send of data is primary for the SPI activity. The received data comes any time later. The received data should be aligned to the SPI bit shifting correctly. Then the data are stored not in the first prepared RAM locations, it is not possible, but in later locations. One 16 bit word needs 1.6 µs. Delay in the ring between two station is, seen here on the SPI clk time between master and slave, approcimately 0.3 µs. It means if 10 station are in the ring, about 3 µs delay for the echo on the master. It means also that the SPI clock should work for at least 2 or 3 data words more as necessary for transmission data, to store the received data, on the master.

The SpiA module prepares the data reading via SPI completely down to the bit to transmit, offering on spi_txD_Out pin of this module. Shifting the data to transmit and provide the data bit in the correct time (clock cycle) is task of this SPiA module.

The module TxSpe transmit data input to SPE offers the start signal for transmission: spi_reqTxData_Inp as input on SpiA, output on TxSpeA: reqDataTx_Out. This signal determines starting the SPI access.

The second task for SpiA is shifting and storing the data from the module RxSpe preparing the receive data input from SPE to write to the controllers RAM. The data comes to the spi_rxData_Inp input of the SpiA from the RxSpe module:

This first image as test Test_SpiShDataTxMastr.awc result shows a master in the Ring topology and an uninitialized slave. The communication in the ring, forwarding data, should be also proper if a slave station is not working in the moment.

+ See code snippet:

The first image shows handling received data in the master of Ring topology. This is appropriate to the chapter above for getting transmission data with the same SPI access. It is the same simulation running, only showing other signals.

The SPI sequence is controlled by the spiMastr.spe_reqTxData_Inp because the transmission data should be read just in time. This is valid also for Master and for slave of Ring topology.

The moment where the shifted data from Rx (orange) are used for shifting in SPI depends on the time delay between start transmitting and the moment of receiving. It is undefined and can jitter. Hence the receiving data are stored with 16 bit to get it in any moment.

The algorithm are the same, it is not distinguished between master and slave. But the conditions are different.

For the slave in Ring topology the first data byte is already received via SPE and can written via SPI. For that see on the

…​TODO more simulation results available, also with different stimuli using the StimuliSelection tool.

For Ethernet with >= 100Mbit/s there is a NTP "Network Time Protocol" (https://en.wikipedia.org/wiki/Network_Time_Protocol) or better PTP (Precision Time Protocol) (https://en.wikipedia.org/wiki/Precision_Time_Protocol) can be used, accordingly to the TSN (Time Sensitive Network) rules (https://en.wikipedia.org/wiki/Time-Sensitive_Networking).

But this technologies works only for the connections >= 100 Mbit/s, because they are not regarded in the original Ethernet 10 Mbit/s topology. The problem of the originaly 10 Mbit/s Ethernet was: The time of transfer of a telegram depends on the status of the line. For the line a Bus Topology is used. It means all station attacks the line. It is deterministic for transmission in a time range in milliseconds, regarding displacement mechanisms, but not for exact time stamps. Due to the presence of the star topology with its continue data stream, which can work with TSN and PTP, a proper time synchronisation for the 10 Mbit/s where never developed.

Now with SPE also the Bus Topology is in focus, with the so named "Multidrop Technology", and that does not support the time synchronization yet and per default.

But, the Ring Topology offers another approach for Time Synchronization:

It means the stations in the ring have the same time, but they don’t know (need not know) the exact absolute time. They work together, out of a global time.

It is possible to insert this stations in a global time (UTC, master clock etc.), but this is task only of the master in the Ring Topology. The master can do so by using one of the possible approaches: Standard Ethernet with TSN and PTP or NTP, or specific variants of SPE (with higher bit rates and Star Topology), which also supports TSN, NTP, PTP. Then the master can forwarding this absolute time in the Ring to all other stations with the Ring Cycle Synchronization, described following.

The approach of the Ring Cycle Synchronization is:

All Stations in the Ring should work synchronous. It means

This is all necessary for example in control of electrical signals.

The cycle for this can be for example 50 µs, as also a little bit longer if possible, …​ 1 ms.

The goal is: Do that with a jitter less as possible and/or necessary.

In the Ring cycle the time stamp existing in the master can be forwarded to all slaves if they need an absolute time for processing. But often only the master may need this.

The master should transmit the telegram starting with the frame_in hardware signal. This signal can/should be produced in the controller by a PWM output. The PWM with the time of the master determines the time of transmission.

On frame_in on master first the preamble with sync bits are transmitted. After a determined number of sync bits, hence a determined time, the SFD Start Frame Delimiter is sent, after them the data.

The first slave in the Ring receives firstly the sync bits. During the sync bits the Slave tunes its central CE clock enable signal due to the sync bit edges (the dataCE_Out of the module RxSpe preparing the receive data input from SPE. This is done in the module Synchronization of the internal CE clock to the signals from outside. It means on receiving the SFD the clocks are synchronized already.

With the SFD the signal frame_out is produces as output of the FPGA to use as input to the controller. This signal has a minimal jitter doe to the clock sync capability (measured 30 ns) and a known delay. With the frame_out as input to the controller either an interrupt to process the data can be start. Or better, an internal PWM can be controlled by a PLL (Phase Look Loop) algorithm, see next chapter. In both case the interrupt starts synchronous (using PLL before receiving the SFD, force an interrupt immediately after the SFD). This interrupt can put and get data to and from the RAM where data for SPE are written and read (via SPI). It means the data exchange are also related to the ring cycle. Always new received data are processed and always new processed data are transmitted. Of course this data timing should be tuned to the telegram timing.

The next slave stations in the Ring receives the SFD in a time which is exact related to the receive moment in the Slave before, because the transmission is done with the central CE clock, which is synchronized to the dataCE_Out of the receiver module with measured 30 ns jitter.

But because the jitter may be added, the next station has a jitter with double spread, but with a Gaussian normal distribution, because the jitter between one station may be seen as accidently. Due to the real clock frequencies, beating can also occur. All in all the jitter is one step greater to the next stations. On 10 stations 300 ns jitter is expectable. But this is not too much.

The jitter can be reduced between each cycles even by the PLL control.

The solution of PLL control is individual for different controller. The principle is:

It means while PLL controlling the interrupt cycle is a little bit lesser or greater, not constant with the same reload value. A constant cycle has usual not the same time as in the master cycle because of quartz frequency tolerances. It would run away by accumulation of time. Hence the time should be adjusted sometimes a little bit.

The different length of an interrupt cycle is a jitter between the Ring cycle (telegram cycle) and the internal timer and interrupt. The range of this jitter depends on the resolution of the timer. If the timer both for interrupt and capture runs with 10 MHz only (100 ns), then the jitter is of course > 100 ns. Because of some small inaccuracies the jitter may be in range of 300 ns. This is added to the telegram jitter (from 30 ns in the first station to 300 ns in the 10th station). A sum of 600 ns jitter for a 50 µs interrupt cycle is not too far. But for analog measurement and also for the PWM output this can be on a limit.

Another possibility for synchronization of the controller with the Ring cycle is: Using a 10 MHz or 5 MHz output signal caused by the internal central CE clock as clock input for the processor. Processors often has a PLL for the internal clock to generate a higher clock frequency from a Quartz with lower frequency. If the FPGA output is used as clock input for the controller, the controller has not an own abbreviating Quartz frequency, and the PLL is not necessary. Measurement the time of frame_in should be used only for the first synchronization and also for checks.

For this solution it should be known that the 10 MHz or 5 MHz clock output can have abbreviations from the contant frequency because of the clock synchronization Synchronization of the internal CE clock to the signals from outside in the FPGA itself. The CE period switches between 9..10 internal clock periods (90..100 ns) or between 10..11 (100 .. 110 ns). This unrest should be processed by the controller’s PLL.

Hence the best solution is: The FPGA clock itself does not come from the Quartz, it does come from a PLL in the FPGA. Then each FPGA can be synchronous to the master’s quartz frequency. And also, the controller in the master is forced by the FPGA quartz or vice versa (maybe better). Hence only one quartz frequency exists in the whole ring. All is synchronous in one ring. Another related ring can be used also the same controller quartz if it is mastered by the same controller. This is the best solution of exact cycle synchronization.

Because of the cycle synchronization so far as possible all stations have the same time, independent whether they use (and knows) the time stamp itself or not.

The trigger for the data exchange on master is the frame-in Signal on FPGA. This is produces per hardware by for example a PWM output, see Chapter Solution frame_in/out and PLL.

The FPGA is the master for the SPI communication. It means, the FPGA as SPE-master starts the SPI data exchange immediately after the frame_in. To resolve this SPI transfer the controller have to be initialized for SPI-data transfer before the frame_in signal comes. For the timing for a cyclic interrupt it means, firstly the initialization of SPI-transfer should be done. The moment to do depends on the programm stepping (machine codes) and should not jitter too much. The frame_in signal should be produces by a PWM hardware (puls widht modulation) which should be part of a controller. Then the moment of output the falling edge of frame_in can be tuned by the compare value of the PWM. It can be tuned in software, but the value should be fixed in run time.

Now after frame_in leading falling edge, the SPI should output the data. It depends of the controller how does it work. Tip: Use 16 bit per data word. Often either a FIFO (fist in first out) register is part of the SPI interface in the controller, or DMA (direct memory access) can be used, or both in combination.

For FIFO the data which should be read from the FPGA should be written into the FIFO register structure before the frame_in edge comes.

For DMA the DMA controll registers should be initialized for this cycle before the frame_in edge comes.

For both, both should be initialized.

The fast image should show the timing

On the slave the timing should be similar. But not the step_in is the trigger, the data comes with receiving a telegram. Exactly therfore SPE-master and SPE-slave should be synchronized in the cycle time, see chapter Ring Cycle Synchronization - approach. Then the receive telegram does not come unexpecting, it comes in the expected time range.

Before the receiving is expected, also (as in SPE-master) the SPI interface of the controller should be initialized. All other is adequate.

As shown in the graphic it is possible to write data for DMA transfer a little bit shortly before they are read from SPI to transmit. The same is with receiving: Using immediately after receive.

But this requires that the timing both from machine code execution in interrupt and the position of data in the SPE telegram are known, stable and tuned. For some simple controlling applications this can be done (need constant calculation time, less jitter). Hence the dead time in the controlling cycle can be reduced. But this is a possibility which can be used in response to the application. You should also regard, that FIFO data should be written (and hence known) before the telegram starts, only DMA data can use this possibility.

In all cases it is not possible to handle the SPI data in software. For that the data rate is too fast (10 Mbit/s, 1.6 µs for 16 bit).

For receiving it is similar. Using a FIFO the first data are written in the FIFO, but some times the FIFO size is too small, and the FIFO is entlees via DMA to the RAM. Then this just in time data can be used. For just in time performance either no FIFO capability should be used or with less size. The DMA should be prior and fast enough for 1.6 µs per access (16 bit SPI access, 10 Mbit/s).

The first data word (16 bit) is used as command as described in …​TODO. The second data word is the sender address. All other data words are user specific, payload in the telegram.

The user should have a data struct (C-language, also in C++), which contains the whole data for SPI beginning with the command and sender word as int16, following by the user data.

The received data are written via DMA to the RAM. The first two words contains the own command and sender, then received data with the sender address follows. Between both they may be fill words with content 0000 on the SPE-master if the response time in the ring is a little bit greater.